1. Field of the Invention
This invention pertains generally to internetwork router operating systems. More particularly, the invention is a method and system for carrying out router configuration transactions and reversions using a centralized database system.
2. The Prior Art
In a routing device, internetwork operating systems (IOS) or more commonly, router operating systems (OS), provide the basic command functions for the routing device as well as various subsystem components which provide specific functions or routines provided by the routing device.
In general, routing devices carry out the operation of reliably transferring network messages or packets between a network of coupled devices, or a collection of such networks. A reliable transfer protocol is provided by the IOS for carrying out such operation. Additionally, an interface in communication with a Configuration (config) subsystem is provided which allows a user of the routing device to configure the operations of the routing device.
The user may configure, for example, the IP address of a serial interface facility or the default route for the routing device. A config command issued by the user is received by the config subsystem and processed therein. The config subsystem determines from the config command issued by the user which client Subsystem is affected by configuration information contained in the config command. The config subsystem then carries out a communication exchange with the affected client subsystem to deliver the change in configuration information.
However, router devices typically include a plurality of client subsystems which manage specific functions, requiring multiple dependencies between the config subsystem and such client subsystems. Furthermore, client subsystems often have multiple dependencies with other client subsystem. For example, the PPP subsystem is dependent upon the IP subsystem for Internet address information and the AAA subsystem for user authentication and credential information. These and other subsystem dependencies as is known in the art prevent modularity in subsystem design and implementation within the IOS of the router.
Another drawback with current subsystem implementation schemes arises when temporary configuration changes to a subsystem are to be carried out. A temporary change is desired when, for example, a user of the routing device wishes to test a particular configuration to analyze the efficiency of such configuration, but would like the opportunity to subsequently revert or xe2x80x9cback-outxe2x80x9d of the change if desired. During such a configuration sequence, multiple transactions will typically need to be carried out between various subsystems. For example, where a user configures the IP address of a serial facility port, the config subsystem will communicate the new IP address to the IP subsystem. In turn, the IP subsystem will communicate to the PPP subsystem that serial facility port has new IP address information. When the changes are to be aborted or otherwise reverted, a similar chain of communication is necessary to complete the task of reverting prior changes. Such multiple dependencies between the various subsystems of the IOS make common transactions cumbersome and unnecessarily complicated. Furthermore, design and development of the various subsystems of the IOS must take into account these multiple dependencies requiring longer design and development time.
Another situation where a temporary change is desired is when a user connects to the router via a xe2x80x9cdial-inxe2x80x9d connection port. Dial-in connections are provided by a plurality of subsystem of the IOS. Certain default settings may be configured for most users. However, specialized settings may be configured for certain users, such as network administrators who have particular access privileges, for example. Where a user connects via a dial-in connection, a dialer subsystem communicates with an AAA subsystem to provide name and password information. Responsive to this communication, the AAA subsystem determines the access credentials of the dial-in user from the name and password information and communicates with a PPP subsystem. The access credentials provide, among other things, the configurations for the user at the dial-in connection port. The PPP subsystem then sets the port configurations for the user according to the user""s access credentials thereby enabling point-to-point communication for the user.
When the user disconnects, the PPP subsystem, the AAA subsystem and the dialer subsystem need to communicate with each other to restore default settings. This situation presents another illustration where multiple dependencies between the various subsystems of the IOS make common transactions cumbersome and unnecessarily complicated.
Yet another disadvantage with current IOS transaction methods arises when configuration command issued by a remote user of the routing device causes the user to be disconnected. Such configuration commands while not permanent prevent the user from remotely reconnecting to the routing device to correct the configuration. Normally, the user would need to directly interface with the routing device to correct the configuration, or otherwise manually restart or xe2x80x9crebootxe2x80x9d the routing device to discard the current configuration and restore the previous configuration. Current transaction methods do not provide a facility or method for sensing such disconnection events and for restoring the previous connection upon the discovery of such disconnection.
Accordingly, there is a need for a method and system for carrying out router configuration transactions wherein the various subsystems of the IOS are modular and independent. More generally it would be advantageous to have a router configuration transaction method which does not rely upon multiple dependent subsystems and which uses a centralized information provider for router configuration information. The present invention satisfies these needs, as well as others, and generally overcomes the deficiencies found in the background art.
An object of the invention is to provide a method and system for transacting routing device configurations which overcomes the prior art.
Another object of the invention is to provide a method and system for transacting routing device configurations using a centralized database system for storing and retrieving configuration data.
Another object of the invention is to provide a method and system for transacting routing device configurations which does not require multiple dependencies between subsystem applications of the router.
Another object of the invention is to provide a method and system for transacting routing device configurations which allows the subsystem applications of the router to be modular and independent of each other.
Another object of the invention is to provide a method and system for transacting routing device configurations which allows the user of the router device to revert changes made during the transaction.
Another object of the invention is to provide a method and system for transacting routing device configurations which allows changes to be reverted upon the occurrence of predefined events.
Another object of the invention is to provide a method and system for transacting routing device configurations which allows the user of the router device to commit changes made during the transaction.
Another object of the invention is to provide a method and system for transacting routing device configurations which allows changes to be committed upon the occurrence of predefined events.
Further objects and advantages of the invention will be brought out in the following portions of the specification, wherein the detailed description is for the purpose of fully disclosing the preferred embodiment of the invention without placing limitations thereon.
The present invention is a method and system for transacting routing device configurations using a centralized information provider or database system. The method of the invention is provided by operating system software which is run or otherwise executed on the routing device (router). The method of present invention is implemented by software which is stored on a computer-readable medium, such as computer memory, for example.
The invention receives configuration commands from a user of the router. The invention then communicates the configuration command to the centralized database system. The centralized database system manages a storage structure, which is preferably a database tree having a plurality of tuple nodes, where each tuple node contains configuration data for the router. The centralized database then carries out the configuration change in the appropriate tuple node using the configuration information provided in the configuration command issued by the user. The invention allows the user of the router to xe2x80x9cback-outxe2x80x9d of such transactions by reverting the configuration of the affected tuple node to its previous or original state. The invention also reverts the configuration of the affected tuple nodes upon the occurrence of certain events as described in more detail below.
In its most general terms, the method of the invention comprises software routines and algorithms which are generally provided as part of an operating system which is executed in a router device. The operating system software which is also known as internetwork operating system (IOS) comprises a plurality of subsystems, each of which perform functions for the router.
One of the subsystems provided by the IOS is a centralized database system (sysDB). The sysDB executes as a susbsystem component in the router and provides a centralized storage and retrieval facility for configuration information required by other subsystems of the IOS. The configuration information stored on the sysDB may include, for example, Internet protocol (IP) addresses, Ethernet configurations, subnet masks, default routes, protocol configuration, name server information, user and password data, access levels, and other router data as is known in the art. As noted above, prior art router implementations have required the individual subsystems to handle storage and retrieval of configuration information related to the corresponding subsystem (i.e., IP subsystems contained IP configuration data, AAA subsytems contained user authentication information). The present invention employs a centralized sysDB which handles storage and retrieval tasks normally assigned to various subsystems. By centralizing such configuration information in a sysDB, multiple dependencies between the other individual subsystem are avoided or greatly reduced. This arrangement allows the subsystem design and implementation to be modular. Subsystems may be added and removed with greater ease due to the lack of multiple and prevalent dependencies.
The sysDB subsystem preferably employs a hierarchical name space scheme in a tree format (sysDB tree) for data storage and retrieval of configuration and other information for the router. Each branch or leaf on the tree is treated as a node or a xe2x80x9ctuplexe2x80x9d. In an illustrative example, the sysDB tree employs a naming convention analogous to the UNIX(copyright) file system where intermediate nodes of the tree are analogous to UNIX(copyright) directories and where leaf nodes are treated as files and data which are associated with the files. In the preferred embodiment, each node or tuple in the sysDB tree has a pointer to its parent node, a pointer to its next peer, and a pointer to its first child. With this arrangement, all the children of a tuple can be iterated by using the first child as the head of a link list and traversing through the corresponding peer of each child. While the sysDB described above employs a tree structure for data storage and retrieval, other data storage facilities known in the art may be utilized including, for example, a table, btree or relational table scheme without deviating from present invention disclosed herein.
The sysDB subsystem is operatively coupled to the other subsystems of the IOS for providing transactional services as described herein. An illustrative IOS may include an Internet protocol (IP) subsystem, an Ethernet subsystem, a dialer subsystem, a point-to-point (PPP) subsystem, an authentication (AAA) subsystem, and a config subsystem, each subsystem operatively coupled to the sysDB subsystem, but not coupled to each other. As is known in the art, the IP subsystem manages the Internet addresses for various port facilities on the router; the Ethernet subsystem manages the Ethernet port facilities on the router; the dialer subsystem manages the dial-in communication access; the PPP subsystem manages the point to point protocol functions on the router; the AAA subsystem manages the user authentication process on the router; and the config subsystem provides configuration management for the router.
Methods for configuring a router are well known in the art and typically involve manual configuration and/or automatic configurations. Manual configurations are provided by a user of the router and are typically issued using configuration commands at a computer or other data processing device, which is operatively coupled for communication to the router. Normally, the user accesses the router using a telnet software program, wherein a user is presented with the current configuration as provided by the config subsystem from data stored in the sysDB. The user then issues configuration commands to the router.
Automatic configurations are routines that provide configuration commands which are executed upon certain events. For example, when a user connects to the router via a xe2x80x9cdial-inxe2x80x9d connection via a modem, the dialer subsystem, the AAA subsystem and the PPP subsystem manage configuration information required to provide access to such dial-in user. In the present invention, configuration changes are communicated to the sysDB, rather than to one or more of the various subsystem which is authoritative for such configuration data as is carried out in prior art implementations.
The invention provides a technique for carrying out router configuration transactions using the centralized database (sysDB) provided by the IOS wherein configuration transactions are tracked and maintained by the sysDB and may be reverted upon the request of the user of the router device or upon the occurrence of certain events. In general, manual configuration requests are received by the config subsystem from commands provided by a user. In response to this configuration request, the config subsystem communicates to the sysDB the proposed changes which were issued by the user. The sysDB receives the proposed changes and creates a transaction therefrom. As an aspect of this transaction, the sysDB determines which node or tuple in the sysDB tree is affected. The sysDB then iterates or navigates to the affected tuple of the sysDB tree. The sysDB determines whether the current tuple is already locked by another transaction. Variously locking methods known in the art may be implemented, however, in the preferred embodiment of the present invention, a lock is indicated in a tuple by the existence of an xe2x80x9coldxe2x80x9d value. The existence of an xe2x80x9coldxe2x80x9d value communicates that another transaction has already modified the present value of the tuple. If the tuple is already locked by another transaction (i.e., an xe2x80x9coldxe2x80x9d value already exists at the tuple), then the proposed changes issues are refused and a notification is sent to the user to indicate the refusal.
If the tuple is not already locked by another transaction, the sysDB stores the new value from the proposed changes into the tuple while preserving the original value as xe2x80x9coldxe2x80x9d data. As rioted above, the existence of an xe2x80x9coldxe2x80x9d value locks the current tuple preventing future modifications to the tuple, until the user either reverts the transaction or commits the transaction as described in further detail below. In certain cases, an array may be provided at a particular tuple to provide a plurality of values at the tuple node. An array may be preferred when a particular port facility may take on one or more values.
The sysDB performs a similar transaction for configuration commands or messages which originate from various other subsystems. For example, when a user connects to the router via a xe2x80x9cdial-inxe2x80x9d or PPP connection, the AAA subsystem defines the access privileges and network configurations of the user in the sysDB. In this example, configurations to the serial port need to be defined where the configurations are particular to the user who dials in. For example, an IP address may be assigned to the user, access privileges may be assigned to the user, and other pertinent data may also be defined. Using the configuration data provided by the AAA subsystem to the sysDB, the PPP subsystem then provides Point-to-Point protocol communication to the user. Because various users may dial in at different times to access the same serial port, configurations to the port are made at the time the user connects. Normally, default configurations are set for most users, and specific configurations may be set for certain users requiring special privileges.
During a PPP connection, the dialing subsystem receives the name and password credentials of the user and communicates these credentials to the AAA subsystem for authentication. Normally, the user credentials are passed from the dialer subsystem to the AAA subsystem directly rather than through the sysDB. However, an alternative arrangement may be provided wherein the user credentials are communicated from the dialer subsystem to the sysDB, and then communicated from the sysDB to the AAA subsystem to provide additional modularity between the dialer subsystem and the AAA subsystem.
The AAA subsystem queries the sysDB to verify the access privileges of the user based on the name and password provided to the dialer subsystem. The sysDB replies with the access privileges requested. The AAA subsystem then configures the router by initiating a transaction request with the sysDB. The transaction steps are similar to those described above for manual configuration using the config subsystem. Namely, the sysDB receives the configuration request and provides an iterating function to navigate to the affected tuple; the sysDB also verifies the lock status of the affected tuple to prevent overlapping transactions; and if the tuple is not currently locked, the sysDB records the new data into the tuple data store while preserving the previous data as xe2x80x9coldxe2x80x9d data. The transaction request carried out by the AAA subsystem may configure one or more tuples within the sysDB tree because configuration of a dial-in connection may involve configuration of a plurality of router items including, for example, configuration of the designated port for PPP operation, configuration of the IP address for the user, and other pertinent configurations for PPP operation as is known in the art.
The sysDB then commences a verification and/or notification routine with the PPP subsystem to indicate that PPP services have been configured. The verification routine is described in further detail in copending application Ser. No. 09/416,312 entitled METHOD AND SYSTEM FOR VERIFYING CONFIGURATION TRANSACTIONS MANAGED BY A CENTRALIZED DATABASE filed on Oct. 12, 1999 which is incorporated by reference herein. The notification routine is described in further detail in copending application Ser. No. 09/416,308 entitled SUBSYSTEM APPLICATION NOTIFICATION METHOD IN A CENTRALIZED ROUTER DATABASE, filed Oct. 12, 1999 and is incorporated herein by reference. The PPP receives the verification and/or notification and commences protocol services for the user at the designated port as is known in the art. Alternatively, the PPP subsystem may include routines for monitoring or otherwise periodically ascertaining certain values in the sysDB. In this case, the PPP initiates protocol tasks when certain configurations are made by the AAA subsystem in the sysDB.
Transactions executed by the sysDB where changes are made to the configuration information in the sysDB tree may be reverted upon commands issued by user of the router or upon the occurrence of certain events. After the sysDB is reverted, the old data is restored to the original value, and the changes are discarded. As noted above, changes to the configuration information in the sysDB are carried out by a transaction performed by the sysDB. Each transaction within the sysDB is preferably identified by a transaction name or identification (ID). Where a command or message from a subsystem to revert a transaction is issued to the sysDB, the sysDB carries out the operation of iterating to the affected tuple based on the transaction ID and saving the xe2x80x9coldxe2x80x9d data as the current or default value for the tuple. The previous changes are discarded and the xe2x80x9coldxe2x80x9d data field value is purged or otherwise deleted. Purging the xe2x80x9coldxe2x80x9d data field value removes the lock from the tuple allowing transactions to be made to the tuple once again.
Interested subsystems are notified about transaction abort by normal verification/notification process. In this manner, all subsystems view changes as normal changes either done manually or automatically.
Certain events may be used to trigger the reversion of certain transactions. For example, when a dial-in user disconnects from the router, the transaction which defines the user access privileges must be reverted. In this case, the PPP subsystem which monitors the communication of the user, senses the disconnection of the user from the router and communicates a disconnection message to the sysDB. In response to this disconnection message, the sysDB notifies the AAA subsystem of the disconnection. Responsive to this disconnection notification, the AAA subsystem communicates a transaction revert or abort signal to the sysDB to delete the configurations made as part of the PPP connection. In response to the cancellation message, the sysDB restores the configuration to the sysDB tree in the manner as described above.
Certain configuration transactions may be committed rather than discarded. Committing transactional changes discards the xe2x80x9coldxe2x80x9d value and accepts the new value as the default value. For example, a user of the router after trying out several configuration changes to the router, may determine that the current changes are the desired changes for operation. Here, the user will transmit a commit message which is received by the config subsystem. The config subsystem will communicate a request to commit the current configuration. In response to this request, the sysDB carries out the operation of iterating to the affected tuple, and purging or otherwise deleting the xe2x80x9coldxe2x80x9d data field value. The current value made during the initial change now becomes the default value for the tuple. As noted above, purging the xe2x80x9coldxe2x80x9d data field value removes the lock from the tuple allowing transactions to made to the tuple once again.
In some cases, the invention provides that configuration changes may be grouped into a transaction group. The transaction group includes one or more transaction ID""s which identify the configuration changes made as part of the group. In turn, a transaction group may be reverted or committed together. The steps for reverting a transaction group comprise reverting each transaction ID within the group wherein the reverting steps are those described above for reverting a single transaction. Similarly, the steps for committing a transaction group comprise committing each transaction ID within the transaction group wherein the committing steps are those described above for committing a single transaction.